[closed] Question about purpose of Base Artifacts
Good day,
I think this one is pretty simple to answer. My impression is that the purpose of Base Artifacts, within a project, is to promote re-use of requirements.
However, I have noted (and tested) that whenever I change a requirement in a Module that is in a specific folder, the base requirement also gets altered.
This seems like it would be a problem for other Modules that re-use the requirement. Either that, or I seem to be misunderstanding the purpose and use of Base Artifacts.
Can someone clarify the purpose and best way to utilize Base Artifacts?
Thanks!
Mary
The question has been closed for the following reason: "The question is answered, right answer was accepted" by rschoon Oct 04 '22, 2:54 a.m.
Accepted answer
Even though I still don't fully comprehend IBM's intent & usage of DNG's modules, I'll present how we have organized our data.
We reuse requirement thru a stream strategy.
I have a single 'Base' stream which contains the full superset of all requirements.
All new requirements are added to the 'Base' stream.
I do all my linking between requirement artifacts in the 'Base' stream.
When a new project kicks off, I branch a 'Project' stream. In the project stream, I can modify the artifact's project-specific attributes, such as, state, component(s) affected, etc.
I refrain from updating the Req Name & Description, because this is the reusable part of the requirement. I only update the artifact's reusable-specific attributes in the 'Base' stream.
BTW, project-specific and reusable-specific attributes are defined in our organization's requirement management strategy.
So, why use modules? Since the Project branch references the superset of requirements from the Base Stream, I use a module to 'collect' and 'organize' the applicable requirements for that specific project. In other requirement tools, I've either 1) used an "Applicability" attribute to indicate requirements are applicable to a project, or 2) deleted the non-Applicable requirements from the project 'space'.
I know that DNG allows you to do some actions on requirements in Modules that don't impact the Base Artifacts; like tags, comments, links. But I don't have a need for those items to be module-specific. I am also nervous trying to differentiate between module & base links. I think this is an area of user error. But, I would like to hear from others how they use module links.
Hope this sheds some light on how we use modules.
BTW, we're always learning, so happy to hear other's solutions and problem areas.
6 other answers
Hi Mary,
The base artifact concept is simply to allow reuse of artifacts in multiple locations.
It does not address the idea of parallel variants of the same requirement co-existing.
The requirements configuration management feature introduced in version 5 addresses the idea of having multiple parallel variants of a single requirement at the same time.
The problem with the base artifact implementation in DNG as I see it is that 90% of the time a requirement appears in a module that is the only place it appears so forcing the users to deal with things like base artifact versus module context linking adds unneccessary confusion to using DNG for everyday users.
It also means that module oriented features like attribute value inheritance have been left out which is another short-coming of DNG.
The simple answer is:
- The base artifact (so the artifact in the folder) owns the artifact text, title and all attributes.
- The artifact in the module(s) retrieves the artifact attributes and text information from the base artifact.
So if you make any change to the base artifact text or attributes, it will also show these changes to the module based artifact (in all modules if it exists in multiple modules)
And if you make any change to the module based artifacts text or attributes, in fact these changes are written to the base artifact, and so of course these changes will also show on the base artifact.
Links however, can be specific to the module based artifact. (so if you add a link to an artifact in the module, it will not show this link for the base artifact)
But when you add a link to the base artifact, it will also show this link for the module artifact in all modules.
Hi Mary,
We have situations where there are what we call Core requirements that apply to all business units, and other requirements that are specific to a particular business unit. We assign the Core Artifacts a unique Artifact Type (e.g., Core Requirement) and then limit who has permission to modify that Artifact Type. Users can add the Core requirements to their Modules, but unless they have permission, they won't be able to edit them. We store the core artifacts in Modules in a Core Requirements Folder, so they're easy to find.
In DOORS 9 we would use links to accomplish the same thing, but there you'd have to flip back and forth between modules. This way, by reusing the Core requirements, users can see everything in one module, in context.
The only time we have a need to visit the base artifacts is when someone accidentally removes an entire section from a Module. While the base artifacts are still available and can be added back to the Module, it's not pretty because they are not in the same hierarchical order.
With 6.0.6 there's an option to designate the folder in which the base artifacts reside. Some of our groups have chosen to use this, so we name it "Z: Foldername" so it appears at the end of the Folder list. It still creates a separate 'base artifact' sub-folder for each Module, but they are all in one place (under Z: Foldername) rather than under each folder in which a Module is created.
If you work primarily in Modules, I think you're safe to tell your users to ignore base artifacts unless they accidentally remove something from a module. I should add that we take away "delete" authority entirely, so they cannot permanently delete from a module, they can only "remove" artifacts (previous DOORS 9 users were too used to 'undelete', which doesn't exist in DNG). We do have a Team Lead role for each project, and they have Delete authority so if someone has a big section that needs to go away permanently, they can have the Team Lead remove and delete for them.
Regards,
Carol
It's a potential minefield - what you don't want is changes propagating to a module that is supposed to be a defined release state (the only way around this is to publish as a document and state that the document reflects the formal issued state and that it takes precedence over the module content).
It doesn't help that baselines are set across a project not at module level.
Regards
Nic
I can agree with the points above:
Base artifacts are convoluted and dangerous. I avoid them, and see few practical use cases for them.
Maybe using them to maintain documents with a high degree of redundancy could work, but I would only do that with descriptive texts, rather than actual requirements.
Besides the uses that have been mentioned above I've been considering using Base Artifacts for global variables.
Consider the following situation:
Customer Requirement 001
<-- satisfied by:
System Requirement 002, System Requirement 003
Now the customer changes his mind about the validation method, which has been initially delivered as an attribute of 001.
Usually this means, I'll have to follow the two links to 002 and 003 and manually adjust the derived requirement's attributes.
Now if all children of 001 point to the requirement 001, and are made to display the validation method of 001 via the "Link--> Format Display", the validation method of 001 gets effectively "inherited" to 002 and 003.
If you were to decide that Requirement 003 now needs to have a distinct validation method from 001, you could even point it to its own (003) Base artifact and adjust it accordingly.
While this might be useful for working within DNG, it effectively blocks data exchange via Excel because as far as I know, there is no way to natively export linked contents.
It also adds another layer of inconsistency in the tool that will be hard to maintain and explain to users, so for the time being I don't think it's worth it.